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(57) Abstract: An architecture for an automation system is dis- 
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publication/subscription eventing component. The look-up ser- 
vices maintain a database of a number of devices to be controlled 
and monitored, and a database of a number of device objects 
corresponding to the devices. The services can be divided into 
attribute-based and name-based services. The soft-state store 
manages variables regarding the devices and the device objects, 
including heartbeats. The eventing component enables subscrip- 
tions to events related to changes in the variables. The architec- 
ture can include management daemons, such as a monitoring 
daemon that detects problems with power line devices. 
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AUTOMATION SYSTEM 

TECHNICAL FIELD 

This invention relates generally to controlling and monitoring devices and sensors, such 
as devices and sensors that connect to the power line, and more particularly to an automation 
5 system for controlling and monitoring devices and sensors. 

BACKGROUND ART 

Home networking and automation have become more popular. With the number and 
complexity of audio/video equipment increasing, some homeowners are interested in operating 
their equipment more easily. Other homeowners are more concerned about the security and 

1 0 safety of their homes. These homeowners may want to remotely monitor their homes, remotely 
control appliances and other power line devices, and learn when important events occur. For 
example, an important event can be the hot water heater bursting or leaking, or another type of 
event. Power line devices are devices that connect to the power line, usually through a plug that 
connects to an electrical outlet. 

15 Currently, there are two popular home networking infrastructures. The first is phone line 

networking. To provide in-home networking of computers and computer peripherals without 
requiring home rewiring, as is usually required with standard Ethernet networks, the Home 
Phone line Networking Alliance (HomePNA) was formed to leverage the existing phone lines in 
homes. More detailed information regarding the HomePNA can be found on the Internet at 

20 www.homepna.com. While phone line networking allows homeowners to create small local- 
area networks (LAN's) within their homes for the purposes of connecting computers and 
computer peripherals, it has limitations. Significantly, phone line networking typically does not 
allow homeowners to control appliances, lamps, and other power line devices within their 
homes. 

25 A second home networking infrastructure is power line networking. Power line 

networking provides ubiquitous wired connectivity throughout the majority of homes. One type 
of power line networking is known as X10. XI 0 is a communications protocol that allows for 
remotely controlling power line devices, such as lamps and appliances. More detailed 
information regarding the XI 0 protocol can be found on the Internet at 

30 ftp://ftp.scruz.net/users/cichlid/public/x 1 Ofaq. 

Current power line networking, such as X10 networking, is limited. The X10 protocol, 
for example, provides only a rudimentary and low-level framework for controlling and 

1 
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monitoring power line devices. The framework generally does not allow for sophisticated and 
complex device control applications. While automation systems employing existing X10 
technology can be implemented using computers, more typically the systems are implemented 
with relatively less intelligent control centers that only govern a limited number of power line 
5 devices, in a limited manner. When computers are used, the resulting systems are still far from 
ideal. They may be difficult to use, and may not be reliable or robust against equipment failures 
and crashes. 

For the reasons described here, as well as other reasons, there is a need for the present 
invention. 

1 0 DISCLOSURE OF INVENTION 

The invention relates to an automation system for controlling and monitoring devices 
and sensors. The devices can include power line devices, such as lamps, appliances, audio/video 
equipment, and other devices that connect to the power line of a house or other building. The 
sensors can include sensors for detecting the occurrence of emergency-related and other events. 
15 For example, a water sensor located near a hot water heater can detect whether the heater has 
burst, or is leaking. 

The invention provides an architecture for controlling and monitoring these devices and 
sensors in an intelligent, reliable, and robust manner. With respect to intelligence, for example, 
the architecture includes look-up services that maintain a database of all available devices in a 

20 user-friendly manner. Rather than remembering a lamp by an archaic address, a homeowner 

may simply identify the lamp as "the lamp plugged into the eastern wall of the bedroom." Other 
aspects of the architecture provide for sophisticated and complex automation applications to 
intelligently control and monitor devices and sensors. 

With respect to reliability, devices controlled by the system send, or have sent for them, 

25 periodic refresh information to indicate that they are properly functioning. The periodic refresh 
information is referred to as a heartbeat. The architecture includes a soft-state store to store this 
information, and a publication/subscription eventing component to enable subscriptions to 
events relating to changes in this information. If a device becomes inoperative, it stops sending 
heartbeats for the soft-state store to record. Through subscriptions that the eventing component 

30 manages, other components within the automation system can become aware that the device is 
inoperative, and take appropriate recovery action. The architecture can also include a power line 
monitoring daemon, as well as other system management daemons. The power line monitoring 
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daemon detects suspect behavior on the power line that may indicate that a power line device is 
malfunctioning, or that a malicious intrusion into the system is being attempted. 

With respect to robustness, the architecture can have built-in redundancy in the number 
of computers over which the architecture is implemented, as well as in the number of instances 
5 of certain types of important system management daemons. Redundant daemon instances utilize 
a weak-leader approach to determine which among them is the current leader instance that 
should respond to inquiries made to the daemon. If the leader daemon instance fails, one of the 
redundant daemon instances becomes the new leader instance, so that the system does not go 
offline. 

10 The invention encompasses automation systems, automation system architectures, and 

methods of varying scopes. Other aspects, embodiments and advantages of the invention, 
beyond those described here, will become apparent by reading the detailed description and by 
referencing the drawings. 

BRIEF DESCRIPTION OF DRAWINGS 

15 FIG. 1 is a pictorial diagram of an example house in which an automation system of the 

invention can be implemented. 

FIG. 2 is a topological diagram of the automation system of FIG. 1. 

FIG. 3 is a diagram of a software architecture that can implement the automation system 
ofFIGs. 1 and 2. 

20 FIG. 4 is a diagram showing how devices, sensors, and objects are registered with the 

look-up services of the software architecture of FIG. 3, according to an embodiment of the 
invention. 

FIG. 5 is a diagram showing how an object of FIG. 4 can be addressed in two different 
ways, according to an embodiment of the invention. 
25 FIG. 6 is a diagram showing the soft-state store of FIG. 3 in more detail, according to an 

embodiment of the invention. 

FIG. 7 is a diagram showing a power line monitoring daemon as one example of the 
system management daemons of FIG. 3, according to an embodiment of the invention. 

FIG. 8 is a diagram showing how the power line monitoring daemon of FIG. 7 detects 
30 patterns from the power line, according to an embodiment of the invention. 

FIG. 9 is a flowchart of a weak leader election method by which a number of daemon 
instances determine which instance is the leader instance, according to an embodiment of the 
invention. 
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FIG. 10 is a diagram showing an abstract, high-level view of the software architecture of 

FIG. 3. 

FIG. 1 1 is a flowchart of a method showing an example operation of an automation 
system of an embodiment of the invention. 
5 FIG. 12 is a diagram showing the device adapter of FIGs. 1 and 2 in more detail, 

according to an embodiment of the invention. 

FIG. 13 is a diagram showing how the device adapter of FIGs. 1 and 2 can be 
implemented, according to an embodiment of the invention. 

FIG. 14 is a diagram of an example computerized device that can be used to implement 
10 the invention. 

MODE(S) FOR CARRYING OUT INVENTION 

In the following detailed description of exemplary embodiments of the invention, 
reference is made to the accompanying drawings that form a part hereof, and in which is shown 
by way of illustration specific exemplary embodiments in which the invention may be practiced. 
15 These embodiments are described in sufficient detail to enable those skilled in the art to practice 
the invention. Other embodiments may be utilized, and logical, mechanical, electrical, and other 
changes may be made without departing from the spirit or scope of the present invention. The 
following detailed description is, therefore, not to be taken in a limiting sense, and the scope of 
the present invention is defined only by the appended claims. 

20 Hardware Architecture 

FIG. 1 shows a pictorial diagram 100 of an example house 102 in which an automation 
system of the invention can be implemented. The house 102 includes a garage 104, a kitchen 
106, a family room 108, a master bedroom 110, and a den 114, among other rooms. 
Connections coming into and distributed throughout the house 102 include a phone line 1 16, a 

25 power line 118, and an Internet connection 120. The phone line 116 allows residents of the 

house 102 to place and receive phone calls. The power line 118 provides electrical power to the 
house 102. The Internet connection 120 connects the house 102 to the Internet. The Internet 
connection 120 can be a fast, always-on broadband connection, such as a cable modem 
connection or a Digital Subscriber Loop (DSL) line. The Internet connection 120 may also be a 

30 slow, dial-up connection that utilizes the phone line 1 16. 

Not specifically called out in FIG. 1 is that a network has been set up within the house 

102. The network is of the type that connects computers and computer peripherals with one 

another. For example, the network may be an Ethernet network, using dedicated wiring, or 
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using the existing phone line 1 1 6. The network may also be a wireless Ethernet network, or 
another type of network. For purposes of descriptive clarity, this network is referred to as the 
backbone network in the detailed description. The backbone network is distinct from a power 
line network, for example. 
5 Each of the rooms of the house 102 has a number of network adapters and electrical 

outlets, as well as other types of components. The garage 104 has four components pertinent to 
the automation system. The video camera 122 allows remote monitoring of whether the garage 
door 124 is open or closed. The camera 122 is preferably directly connected to the backbone 
network set up within the house 102. The network adapter 128, as well as other network 

10 adapters throughout the house 102, provide for connectivity to the backbone network. The 
garage door opener 130 controls the opening and closing of the garage door 124, and is 
connected to the backbone network through the network adapter 128. 

Electrical power devices that may be controlled using the automation system can be 
plugged into the electrical outlet 126, or into other electrical outlets throughout the house 102. 

15 Electrical power devices are also referred to as power line devices. Power line devices include 
appliances, lamps, audio/video equipment, and other types of devices that are plugged into 
electrical outlets. The power line devices are typically independent from one another. For 
example, a power line device that is a lamp is independent from a power line device that is a 
clock radio, in that the lamp and the clock radio are not aware of each other. The lamp and the 

20 clock radio can each be independently controlled by the automation system. 

In an alcove 132 off the garage 104, there is a hot water heater 134 and a furnace 136. 
Relevant to the automation system is the water sensor 138, which is connected to the backbone 
network through the network adapter 140. The water sensor 138 is located on the floor of the 
alcove 132 and detects the presence water, which may indicate that the hot water heater 134 is 

25 leaking or has burst. 

The kitchen 106 likewise has an electrical outlet 138 and a network adapter 140. As 
shown in FIG. 1, the kitchen also includes a radio-frequency (RF) device 142. The RF device 
142 communicates with an RF bridge 144 that is wired to the backbone network. An example of 
the RF device 142 is a wireless temperature gauge that periodically sends the detected 

30 temperature via RF signals to the RF bridge 144. The den 1 14 in particular includes the RF 

bridge 144, connected to the backbone network through the network adapter 146, with which the 
RF device 142 communicates. The family room 108 also has an RF device 148. The RF bridge 
144 receives RF signals transmitted by the RF devices 142 and 148, and passes them through to 
the backbone network set up in the house 102 via the network adapter 146. The RF bridge 144 
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also receives data from the backbone network intended for the RF devices 142 and 148, and 
passes them through to the devices 142 and 148 by conversion to RF signals. 

A user access point (UAP) 101 is located in the kitchen 106. The UAP 101, and other 
UAP's throughout the house 102, permit users of the automation system to interact with the 
5 system. The UAP 101 can be a touch-screen, flat-screen device mounted on a wall of the 
kitchen 106. The user provides input to the automation system by touching the device, and 
receives output from the system by viewing the screen of the device. The UAP 101 can also be 
a computer, or another type of device. 

The family room 108, in addition to the RF device 148, includes electrical outlets 150 

10 and 152, and a network adapter 154. Audio/video (A/V) devices 156 are connected to an A/V 
bridge 158, through which the A/V devices 156 can send and receive audio, video, and control 
signals through the backbone network set up in the house 102. The A/V bridge 158 is connected 
to the backbone network through the network adapter 154. The family room 108 has a 
thermostat 160 for controlling the heating and cooling system of the house 102. The heating and 

15 cooling system includes, for example, the furnace 136 in the alcove 132 off the garage 104. The 
thermostat 160 is preferably connected directly to the backbone network set up in the house 102. 
A UAP 103 is also located in the family room 108. 

The master bedroom 110 has a network adapter 1 62 and an electrical outlet 164. Of 
particular relevance to the automation system is that a device adapter 166 is directly plugged 

20 into the electrical outlet 164, and a lamp 168 is plugged into the device adapter 166. The device 
adapter 166 allows the automation system to control non-intelligent power devices, such as the 
lamp 168. A subsequent section of the detailed description describes the construction and the 
use of the device adapter 166. A UAP 105 is also located in the master bedroom 110. 

The den 1 1 4 is the room of the house 102 in which the heart of the automation system is 

25 located. There are four computing devices 174, 176, 178, and 180. The computing devices may 
be desktop or laptop computers, for example. The computing device 174 serves as the gateway 
device, through which the backbone network set up in the house 102 is connected to the Internet 
connection 120. The devices 176, 178, and 180 provide the hardware on which the software 
architecture of the automation system is implemented in a distributed manner. The software 

30 architecture is described in detail in a subsequent section of the detailed description. There is 
more than one such device for redundancy and reliability purposes. The devices 174, 176, 178, 
and 180 connect to the backbone network through the network adapter 182, and can receive 
power through the electrical outlet 184. 
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The four computing devices 174, 176, 178, and 180 can be located throughout the house 
102, instead of in a single room, such as the den 1 14. This may be desirable where one or more 
of these computing devices also serves as a UAP. Furthermore, if a circuit breaker for the room 
where one of the computing devices is located trips, only one computing device is affected. The 
5 automation system will still be able to operate over the other, unaffected computing devices. 

The RF bridge 144 of the den 114 allows the RF devices 142 and 148, in the kitchen 106 
and the family room 108, respectively, to communicate with other devices on the backbone 
network set up in the house 102. The RF bridge 144 is connected to the backbone network 
through the network adapter 146, and receives power through the electrical outlet 186. There 

10 are two other bridges in the den 1 14, the IR bridge 188, and the power bridge 192. The infrared 
(IR) bridge 188 allows the ER device 190, and other IR devices, to communicate with devices on 
the backbone network. The IR device 190 sends IR signals to and receives IR signals from the 
IR bridge 188, and vice- versa. Examples of the IR device 190 include a video-cassette recorder 
(VCR) and a remote control, although the device 1 90 can be any type of device. IR signals 

1 5 differ from RF signals in that they require a direct line of sight between the sender and the 
receiver, unlike RF signals. The IR bridge 188 receives power from the electrical outlet 194, 
and is connected to the backbone network through the network adapter 196. 

The power bridge 192 allows devices connected to the power line 1 18 of the house 102 
via electrical outlets to communicate with devices on the backbone network. The power bridge 

20 192 is connected to the backbone network through the network adapter 182, and through the 

electrical outlet 198 receives power and communicates with the devices connected to the power 
line 118. For example, the lamp 168 in the master bedroom 110 can be controlled and 
monitored by the automation system. The device adapter 166 situated between the lamp 168 
and the electrical outlet 1 64 sends and receives signals over the power line 118. The power 

25 bridge 192 transfers these signals from the power line 1 1 8 to the backbone network set up in the 
house 102. 

While the automation system has been shown in FIG. 1 as implemented in a house, the 
system can also be implemented in other types of buildings as well. For example, the 
automation system can be implemented in an office building, a church, a store, a mall, or another 
30 type of building. The automation system can also be implemented without regard to a physical 
structure, such as a building. The components controlled and used by the automation system of 
FIG. 1 are representative components, and are not all required to practice the invention. As an 
example, the IR device 190 and the RF devices 142 and 148 may be omitted. 
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FIG. 2 shows a diagrammatic topology of the automation system of FIG. 1, providing 
another view of the system. The automation system is called out as the system 200 in FIG. 2. 
The backbone network 202 is preferably an Ethernet network, implemented over a dedicated line 
or over the phone line 1 16 of FIG. 1. The system devices 204 include the devices 174, 176, and 
5 178. The devices 204 connect to the backbone network 202 through the network adapter 182. 
The device 174 is the gateway device that connects to the Internet connection 120. The user 
access points (UAP's) 206 include the UAP's 101, 103, and 105. The UAP's 206 are preferably 
directly connected to the backbone network 202. Likewise, the thermostat 160 is directly 
connected to the backbone network 202, whereas the water sensor 138 is connected to the 

10 backbone network 202 through the network adapter 140. The audio/video (A/V) devices 156 are 
connected to the A/V bridge 158, which is connected to the backbone network 202 through the 
network adapter 154. The A/V bridge 158 enables the A/V devices 156 to communicate with 
devices on the backbone network 202. 

The power bridge 192 is connected to the backbone network 202 through the network 

15 adapter 182. Two instances of the same network adapter 182 are shown in FIG. 2 for illustrative 
clarity. The power bridge 192 is connected to the power line 118 through the electrical outlet 
198. Smart power devices 208 directly connect to the power line 118 through corresponding 
electrical outlets 210, and can directly communicate with the power bridge 192. By comparison, 
non-intelligent power devices require interstitial device adapters between them and their 

20 corresponding electrical outlets. For example, the lamp 168 requires the device adapter 166 
between it and the electrical outlet 164 for the automation system to control and monitor the 
lamp 168. Moving to the right of the power bridge 192 on the backbone network 202 in FIG. 2, 
the garage door opener 130 is connected to the backbone network 202 through the network 
adapter 128. The video camera 122 is directly connected to the backbone network 202. 

25 The infrared (IR) bridge 188 is connected to the backbone network 202 through the 

network adapter 196, while the radio frequency (RF) bridge 144 is connected to the backbone 
network 202 through the network adapter 146. The IR bridge 188 enables the IR devices 212, 
such as the IR device 192, to communicate with devices on the backbone network 202. 
Likewise, the RF bridge 144 enables the RF devices 214, such as the RF devices 142 and 148, to 

30 communicate with devices on the backbone network 202. 

Software Architecture 

FIG. 3 is a diagram 300 showing a software architecture 302 for the automation system 
described in the previous section of the detailed description. The software architecture 302 

8 
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specifically has three layers, a system infrastructure layer 304, an application layer 306, and a 
user interface layer 308. The software architecture 302 is preferably implemented over the 
system devices 204 of FIG. 2, such as the devices 176, 178, and 180. An overview of each layer 
of the architecture 302 is described in turn. The architecture 302, which is the central and 
5 critical aspect of the software architecture, is then described in more detail. 

The system infrastructure layer 304 includes look-up services 310, a 
publication/subscription eventing component 312, system management daemons 314, and a soft- 
state store 316. The soft-state store 316 manages the lifetime and replication of soft-state 
variables. The publication/subscription eventing component 312 enables objects, daemons, 

10 programs, and other software components to subscribe to events related to changes in the soft- 
state store 316. The look-up services 310 interact with devices and sensors of the automation 
system, which are indicated by the arrow 318. Specifically, the look-up services 310 include a 
name-based look-up service (NBLS) 320, and an attribute-based look-up service (ABLS) 322. 
The ABLS 322 maintains a database of available devices, and supports queries based on device 

15 attributes. The device attributes can include device type and physical location, among other 
attributes. The NBLS 320 maintains a database of running instances of objects, and supports 
name-to-object address mapping. The system management daemons 314 of the system 
infrastructure layer 304 detect failures of devices, and initiate recovery actions. 

The application layer 306 includes automation applications 324, device objects 326, and 

20 device daemons 328. There are two types of automation applications 324, device-control 
applications, and sensing applications. Device-control applications receive user requests as 
input, consult the look-up services 310 to identify the devices and the device objects 326 that 
should be involved, and perform actions on them to satisfy the requests. The device objects 326 
correspond to the devices and sensors identified by the arrow 318. The device objects 326 

25 encapsulate device- and network-specific details of their corresponding devices, and present 
interfaces for them, such as method calls. Examples of the device objects 326 include camera 
objects for taking snapshots and recording video clips, and garage door opener objects for 
operating garage doors. 

Sensing applications monitor environmental factors, and take actions when a monitored 

30 event occurs. The sensing applications subscribe to events through the eventing component 312. 
Device daemons 328 interact with the devices and sensors identified by the arrow 318, and 
independently act as proxies for them. For example, a device daemon for a sensor can monitor 
sensor signals, and update appropriate soft-state variables in the soft-state store 316 to trigger 
events. 
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The user interface layer 308 provides user access to the system infrastructure layer 304 
and the application layer 306. The user interface layer 308 has three parts, a web browser 
interface 330, a voice-recognition interface 332, and a text-based natural language parser 
interface 334. The browser interface 330 enables the user to browse through available devices, 
5 select devices based on attributes, and control the devices. The text-based natural language 
parser interface 334 is based on a vocabulary appropriate to an automation system, while the 
voice-recognition interface 332 employs voice recognition technology based on the same 
vocabulary. 

The user interface layer 308 preferably supports remote automation. For example, when 

10 the Internet connection 120 is an always-on connection, the browser interface 330 can be used to 
access the automation system from remote locations. The natural language parser interface 334 
provides an email-based remote automation interface. The email daemon 336 periodically 
retrieves email through the Internet connection 120, and parses automation-related requests 
contained in the email. The daemon 336 passes the requests to the automation applications 324, 

1 5 and optionally sends reply email confirming that the requested actions have taken place. Known 
digital signature and data encryption technologies can be used to ensure the security of the 
email. If the user has a mobile phone 338 that supports text messaging, the email daemon 336 
can alert the user with text messages when predetermined events occur. The voice-recognition 
interface 332 can optionally be used with the mobile phone 338, or another type of phone. 

20 FIG. 4 is a diagram 400 showing how one embodiment registers devices, sensors, and 

objects with the look-up services 310. The devices and sensors that are registered include the 
devices and sensors pointed to by the arrow 3 1 8 in FIG. 3. The devices include smart devices 
208, fixed devices 402, and dynamic devices 404. Smart devices 208 are devices that do not 
need a device adapter to interact with the system. Fixed devices 402 are devices that are 

25 permanently affixed at their location, and cannot be moved. An example of a fixed device is the 
garage door opener 130 of FIGs. 1 and 2 5 which is permanently affixed to a garage wall. The 
fixed devices 402 also include electrical outlets and wall switches. Dynamic devices 404 are 
devices that can be moved. An example of a dynamic device is the lamp 168 of FIGs. 1 and 2, 
which can be unplugged from one room and moved to another room. The objects that are 

30 registered include the device objects 326 of FIG. 3, as well as computation objects 406. 

Computation objects 406 do not correspond to any particular device, but are used by daemons, 
applications, and other components of the automation system. Example computation objects 
include language parser objects and voice recognition objects. 
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Through the ABLS administration console 408, the user performs a one-time manual 
task of assigning unique addresses to the fixed devices 402, which registers the devices 402 with 
the ABLS 322. The unique address can be X10 addresses. Additional attributes may be entered 
to associate the devices 402 with physical-location attributes. For example, a wall switch in the 
5 garage can be indicated as the "garage wall switch," in addition to having a unique address. 
Dynamic devices 404 have their device attributes announced to the ABLS 322 when they are 
plugged in and switched on, through the device daemons 328 that act as proxies for the devices 
404. Device objects 326 for the dynamic devices 404 are instantiated when an application 
requests to control the devices 404. The objects 326 can persist for a length of time, so that 

10 repeated requests do not require repeated instantiation. The device objects 326 are instantiated 
by the NBLS 320. Smart devices 208 perform their own registration with the ABLS 322. 
Computation objects 406 are instantiated by the NBLS 320, and require a software component 
or service referred to as the computation object installer 420 to register with the ABLS 322. 

FIG. 5 is a diagram 500 showing how one embodiment addresses an object 502 in two 

15 different ways. The object 502 can be one of the device objects 326 of FIG. 4, or one of the 

computation objects 406 of FIG. 4. The object 502 has one or more synchronous addresses 304, 
and one or more asynchronous addresses 306. The synchronous addresses 504 can include an 
address in the form of a marshaled distributed-object interface pointer, or another type of 
reference that enables real-time communication with the object 502. The asynchronous 

20 addresses 306 can be in the form of a queue name, a marshaled handle to a queue, or other 
address. The asynchronous addresses 306 are used to asynchronously communicate with the 
object 502 when it is temporarily unavailable or too busy, or when synchronous communication 
is otherwise not desired. 

Referring back to FIG. 4, in summary, the ABLS 322 of the look-up services 310 

25 maintains a database of available devices and sensors. The ABLS 322 supports queries based on 
combinations of attributes, and returns unique names of the devices and sensors that match the 
queries. By allowing identification of devices and sensors by their attributes and physical 
locations, instead of by their unique addresses, the ABLS 322 enables user-friendly device 
naming. For example, the user can identify a device as "the lamp on the garage side of the 

30 kitchen," instead of by its unique address. The NBLS 320 of the look-up services 310 maps 
unique names to object instances identified by those names. The NBLS 320 is optionally 
extensible to allow mapping of a unique name to multiple object instances. Both the ABLS 322 
and the NBLS 320 are robust against object failures and non-graceful termination because they 
are based on the soft-state store 316 of FIG. 3. 

11 
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FIG. 6 is a diagram 600 showing one embodiment of the soft-state store (SSS) 316 in 
more detail. The SSS 316 uses a persistent, or non-volatile, store 608, and a volatile store 606. 
The persistent store 608 is used in addition to the volatile store 606 to save soft-state variables 
over failures, such as system crashes. The persistent store 608 can be a hard disk drive, non- 
5 volatile memory such as flash memory, or other non- volatile storage. The volatile store 606 can 
be volatile memory, such as random-access memory, or other volatile storage. 

The SSS 316 ultimately receives heartbeats 602, and stores them as soft-state variables in 
either the persistent store 608 or the volatile store 606. The heartbeats 602 are periodic refreshes 
from devices, sensors, objects, and daemons, so that the automation system knows they are still 
10 operating. The heartbeats 602 include device heartbeats 610, sensor heartbeats 612, object 

heartbeats 614, and daemon heartbeats 616. The refresh rates of the heartbeats 602 vary by their 
type. The daemon heartbeats 616 may be received over intervals of seconds. The object 
heartbeats 614 may be received over intervals of tens of seconds to minutes. The sensor 
heartbeats 612 may be received over intervals of minutes to hours. The device heartbeats 610 
15 may be received over intervals from hours to days. 

The device heartbeats 610 and the sensor heartbeats 610 are received by the SSS 316 
through the ABLS 322, while the object heartbeats 614 are received by the SSS 316 through the 
NBLS 320. The SSS 316 directly receives the daemon heartbeats 616. When an entity does not 
send a heartbeat as required by its refresh rate, the entity ultimately times out and is removed 
20 from the ABLS 322 and the NBLS 320. An entity in this context refers to a device, sensor, 
object, or daemon. 

The SSS 316 preferably performs soft-state variable checkpointing. For a given refresh 
rate threshold, heartbeats that occur above the threshold, and thus are updated with high 
frequency, remain in the volatile store 606, to decrease overhead. Recovery of these high- 

25 frequency heartbeats from failure of the SSS 3 1 6 is through new refreshes. Conversely, 

heartbeats that occur below the threshold, and thus are updated with low frequency, are persisted 
in the persistent store 608. Recovery of these low-frequency heartbeats from failure of the SSS 
316 is through restoration of the persistent soft-state variables in the store 608. This is because 
waiting for the next heartbeat may take too long. Downtime of the SSS 3 16 is preferably treated 

30 as missing refreshes for the soft-state variables. 

The publication/subscription eventing component 312 allows subscriptions to events 
resulting from the change, addition, or deletion of the soft-state variables maintained by the SSS 
316. The subscribers can include applications, daemons, and other software components of the 
automation system. The eventing component 312 sends events to subscribers when the kinds of 
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changes to the SSS 316 match their corresponding event subscriptions. The component 312 
receives the changes in the soft-state variables from the SSS 316. From these changes, it 
formulates events as necessary. 

FIG. 7 is a diagram 700 showing one embodiment of the system management daemons 
5 314 of FIG. 3 in more detail. In particular, the system management daemons include a power 
line monitoring daemon 702. The power line monitoring daemon 702 detects reliability, 
security, and other problems with automation system devices that use the power line. The 
daemon 702 can use pattern-based detection for detecting unacceptable power line activity, 
model-based detection for detecting acceptable power line activity, or both. Pattern-based 
10 detection employs a database of unacceptable power line patterns that, if detected, trigger an 
event. For example, faulty devices and external interferences may produce meaningless 
repetitions or interleaving of commands. By comparison, model-based detection employs a 
model of acceptable power line patterns. Power line patterns that do not conform to the model 
also trigger an event. 

15 FIG. 8 is a diagram 800 showing how one embodiment uses the power line monitoring 

daemon 702 to detect problems on the power line 118. The daemon 702 monitors the power line 
1 18 for problems that result from intrusions 802, atypical behaviors 804, and interferences 806. 
The daemon 702 matches patterns from the power line 118 against unacceptable power line 
patterns stored in the pattern database 808. The daemon 702 also tests the patterns against the 

20 pattern model 810 of acceptable power line patterns. If matching the patterns against the 

unacceptable power line patterns stored in the database 808 yields a positive match, or testing 
the patterns against the model 810 of acceptable power line patterns yields a negative test, the 
daemon 702 generates an event. The event corresponds to the situation that an unacceptable 
pattern has been detected on the power line 1 1 8. Other daemons, objects, and programs can 

25 subscribe to the event through the eventing component 312, which is not specifically called out 
in FIG. 8. 

The monitoring daemon 702 maintains a log file 812 of all detected power line patterns. 
The patterns stored in the log file 812 include both acceptable and unacceptable power line 
patterns. An analysis tool 814 can be used by a user to determine whether to add new 
30 unacceptable power line patterns to the database 808, based on the patterns stored in the log file 
812. The analysis tool 814 can also be used to determine whether the model 810 of acceptable 
power line patterns should be modified, based on the patterns stored in the log file 812. 

For each system management and other daemon, there can be more than one instance of 
the daemon for redundancy purposes. For example, an instance of the power line monitoring 

13 
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daemon may reside on each of the system devices over which the automation system is 
implemented. If one of the system devices fails, the redundancy ensures that the automation 
system itself does not fail. For a number of instances of the same daemon, a leader daemon 
instance must be determined. The leader daemon instance is the active instance, which responds 
5 to requests to the daemon. The other instances do not respond. If the leader instance fails, then 
another instance becomes the new leader instance. 

FIG. 9 is a flowchart of a method 900 showing how one embodiment determines which 
of a number of daemon instances, is the leader instance. The method 900 is specifically a weak 
leader election approach. The approach is weak in that only the leader instance knows that it is 
10 the leader instance. Other instances only know that they are not the leader instance. Weak 
leader election reduces the coordination that is necessary among the daemon instances. 
Requests made to the daemon are multicast to all instances of the daemon, but only the leader 
instance responds. 

In 902, age information is exchanged among all the instances of a daemon. The age 

15 information can include, for example, how long each instance has been online. At each instance, 
904 is performed. Specifically, in 906, each daemon instance determines whether it is the oldest 
instance, based on the age information received from the other daemon instances in 902. If a 
daemon instance determines that it is the oldest instance, then, in 908, the instance concludes 
that it is the leader instance. Otherwise, in 910, the daemon instance concludes that it is not the 

20 leader instance. The method 900 is periodically repeated, as indicated by the arrow 912. 

Furthermore, as indicated by the line 914, when any daemon instance has detected that a failure 
has occurred which may have affected the leader instance, 904 is immediately performed again. 

As a summary of the software architecture described in this section of the detailed 
description, FIG. 10 is a diagram 1000 showing a high-level view of the architecture. The 

25 software architecture 302 resides between the power line 118 and the Internet connection 120. 
The architecture 302 abstracts the manner by which the devices connected to the power line 118 
are accessed and controlled. The Internet connection 120 provides for remote, off-site access 
and control of devices connected to the power line 118, through the architecture 302. The 
notification path 1008 indicates that notifications from the devices connected to the power line 

30 118 move up to the software architecture 302. The notifications can also move up to the Internet 
connection 120 in the case of remote, off-site access and control of the devices. The control 
path 1010 indicates that control of the devices originates either from the Internet connection 120 
or at the architecture 302, and moves down to the power line 1 18 to reach the devices. 

14 

NSDOCID: <WO 01 13185A2_I_> 



WO 01/13185 PCT/US00/22578 
Example Operation of the Automation System 

FIG. 1 1 is a flowchart of a method 1 100 showing an example operation of the 
automation system that has been described in the preceding sections of the detailed description. 
The example operation relates to a remote, off-site user emailing a request to close a garage 
5 door, and receiving by reply email a confirmation response that the request has been performed. 
In 1 102, the request to perform the close garage door command is received by the automation 
system in an email over the Internet. For example, referring to FIG. 3, the email daemon 336 
receives the email containing the request through the Internet connection 120. The email 
daemon 336 uses the natural language parser interface 334 to retrieve the command from the 
10 text of the email, and relays the command to the appropriate application of the automation 
applications 324. 

Referring back to FIG. 1 1, in 1 104, the video camera in the garage is directed to either 
start recording, if it is a moving-picture camera, or to take a before picture, if it is a still-picture 
camera. The starting of the recording and the taking of the before picture are referred to 

1 5 generally as effecting the video camera a first time. For example, referring to FIG. 1, the video 
camera 122 is aimed at the garage door 124 in the garage 1004. The video camera 122 begins 
recording a video clip, or takes a before picture of the garage door 124. The appropriate 
automation application directs the video camera 122 to perform this action through its 
corresponding device object. The device object for the camera 122 is one of the device objects 

20 326 of FIG. 3. Referring back to FIG. 1 1, in 1 106, the command to close the garage door is 
performed. For example, referring to FIG. 1, the garage door opener 130 is used to close the 
garage door 124. The appropriate application directs the device object for the opener 130 to 
perform this command. The device object for the opener 130 is one of the device objects 326 of 
FIG. 3. 

25 Referring back to FIG. 1 1, in 1 108, the video camera in the garage is directed to either 

stop recording, or take an after picture, depending on whether it is a moving-picture camera, or a 
still-picture camera, respectively. The stopping of the recording and the taking of the after 
picture are referred to generally as effecting the video camera a second time. For example, 
referring to FIG. 1 , the camera 122 stops recording the video clip, or takes an after picture of the 

30 garage door 1 24, as directed by the appropriate application through the object for the camera 

122. If the result is a video clip, the clip shows the garage door going from an opened state to a 
closed state, as the close garage door command is performed. If the result is a before picture and 
an after picture, the before picture shows the garage door opened, and the after picture shows the 
garage door closed, after the close garage door command has been performed. 

15 
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Referring back to FIG. 1 1, in 1 1 10, the remote, off-site user is sent a confirmation 
response by reply email. For example, referring to FIG. 3, the appropriate application of the 
automation applications 324 sends the confirmation response email to the user via the email 
daemon 336 through the Internet connection 120. The response email includes the video clip 
5 that has been recorded or the before and after pictures that have been taken. In an alternative 
embodiment, timestamps are stamped on the frames of the video clip or on the before and after 
pictures. The timestamps indicate the relative times during which the close garage door 
command was performed. In another alternative embodiment, the timestamp is digitally 
watermarked in the clip or in the pictures, so malicious doctoring or other modification can be 
10 detected. 

The example operation described is one type of independent verification that can be 
accomplished by the automation system. Independent verification allows users to witness that a 
desired command relative to a desired device has been successfully performed. Video 
confirmation is one type of independent verification. Independent verification can also include 
15 audio confirmation, or other types of confirmation. The independent verification can be 
performed within the user interface layer 308 of FIG. 3. 

Device Adapter 

The automation system that has been described with reference to FIGs. 1 and 2 in a 
previous section of the detailed description includes a device adapter 166 that connects the lamp 

20 168 to the electrical outlet 164. Device adapters, such as the device adapter 166, are employed 
in general to allow non-intelligent devices, such as the lamp 168, to be controlled and accessed 
within the automation system. In particular, the device adapters announce non-intelligent 
devices and their locations to the automation system. 

The device adapter 166 is used in conjunction with the attribute-based lookup service 

25 (ABLS) 322 of FIG. 3. To minimize user administration, a one-time configuration task is 

performed by assigning an address to every electrical outlet in the house that the user would like 
to control, and mapping the address to a unique set of physical location attributes. When a new 
device is plugged into an electrical outlet through a device adapter, its device type and the outlet 
address are announced over the power line to the automation system. To perform the one-time 

30 configuration task, the user assigns a unique address to each electrical outlet or wall switch, and 
records the mapping between the physical location and the address in the ABLS 322. For 
example, when the address "A5" is assigned to an outlet on the backyard side of the kitchen on 
the first floor, the entry "address = A5; floor = one; room = kitchen; side = backyard" is 

16 
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recorded. Once an electrical outlet is assigned an address, a device adapter plugged into the 
outlet is also set to the address. 

FIG. 12 is a diagram 1200 showing one embodiment of the device adapter 166 in more 
detail. To add a non-intelligent device to the system, after having performed the one-time 
5 configuration task, the user plugs the device into the electrical outlet 1204 of the device adapter 
166, and plugs the plug 1202 of the adapter 166 into an electrical outlet. The user sets the 
address of the adapter 166 to match the address of the outlet, by adjusting the controls 1206 of 
the adapter 166. The user also sets the device code and the module code for the device, using 
the controls 1208 and 1210, respectively. The device code is selected from a pre-defined set of 

10 device type codes. The module code specifies the device object class from which a device 
object should be instantiated to control the device. As shown in FIG. 12, the controls 1206 
include two dial switches, while the controls 1208 and 1210 each include one dial switch. Other 
types of controls can be used, such as slider switches and keypads, among others. The controls 
1206, 1208, and 1210 can alternatively be internal controls that are set remotely through a 

15 computer. 

When the non-intelligent device that has been plugged into the outlet 1204 of the adapter 
166 is switched on, the device adapter 166 broadcasts the device code, the module code, and the 
address over the power line in the form of an extended code. The address and the extended code 
can be consistent with the known XI 0 protocol. The subset of system devices 204 of FIG. 2 that 

20 receive the announcement register the device with the ABLS 322 of FIG. 3, and register their 
own device daemons 328 of FIG. 3 as the proxies for the device. The proxies can then be 
employed to instantiate appropriate device objects 326 of FIG. 3 to control the device. 

The device adapter 166 is responsible for sending periodic announcements to the soft- 
state store (SSS) 316 of FIG. 3 so that the proxies can refresh the soft-state variables for the 

25 device. When the device is broken or unplugged from the adapter 166, the adapter 166 

announces that the device has left the system. When the adapter 166 itself is unplugged, the 
periodic refreshes stop and the device's entry in the ABLS 322 of FIG. 3 eventually times out. 
The adapter 166 preferably includes a manual override function so that the user can turn on both 
the device and the adapter 1 66 by using a power switch on the device. 

30 FIG. 13 is a diagram 1300 showing how one embodiment implements the device adapter 

166. The adapter 166 is connected to the power line 1 18 by line 1302. A non-intelligent device 
1314 is connected to the adapter 1 66 by line 1304. The non-intelligent device 1314 can, for 
example, be the lamp 168 of FIGs. 1 and 2. The adapter 166 has a receiver 1306, a transmitter 
1308, a sensor 1310, and a logic mechanism 1312. The receiver 1306 and the transmitter 1308 
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are used to control the non-intelligent device 1314. The receiver 1306 receives commands from 
the power line 118, and can be an XI 0 receiver that receives XI 0 commands. The receiver 1306 
controls electricity from the power line 1 18 to the device 1314, depending on the received 
commands. The receiver 1306 has an on/off status indicating whether the adapter 166 is 
5 plugged into an electrical outlet and receiving power. The on/off status has two states, an on 
state, and an off state. In the on state, the adapter 166 is receiving power, whereas in the off 
state, the adapter 166 is not receiving power. The transmitter 1308 announces joining and 
leaving of the device 1314 over the power line 1 1 8, as instructed by the logic mechanism 1312. 
The receiver 1306 and the transmitter 1308 can be integrated into a single transceiver. 

1° The logic mechanism 1312 determines when to instruct the transmitter 1308 to announce 

leaving or joining of the device 1314. The device 1314 also has an on/off status having two 
states, an on state, and an off state. When the mechanism 1312 detects that the receiver 1306 is 
on, but the sensor 1310 has not detected electricity flowing through the device 1314, it instructs 
the transmitter 1308 to announce leaving of the device 1314. This corresponds to the situation 

15 where the adapter 166 is plugged into an electrical outlet, is receiving power, and is on, but the 
device 1314 is off. When the mechanism 1312 detects that the receiver 1306 is on, and the 
sensor 1310 has detected electricity flowing through the device 1314, the mechanism instructs 
the transmitter 1308 to announce joining of the device 1314. This corresponds to the situation 
where the adapter 166 is plugged into an electrical outlet, is receiving power, and is on, and the 

20 device 1314 is also on. 

The sensor 13 10 is used to determine whether the device is on, or off or broken. The 
sensor 1310 can be a current sensor, detecting whether electrical current is flowing through the 
device 1314. The logic mechanism 1312 can be implemented as software, hardware, or a 
combination of software and hardware. The logic mechanism 1312 can be a state machine, 

25 making decisions regarding when to instruct the transmitter 1308 to announce joining and 
leaving of the device 1314. 

Example Computerized Device 

The invention can be implemented within a computerized environment having one or 
more computerized devices. The diagram of FIG. 14 shows an example computerized device 
30 1400. The device 1400 can implement one or more of the system devices 204 of FIG. 2, or one 
or more of the user access points 206 of FIG. 2. The example computerized device 1400 can be, 
for example, a desktop computer, a laptop computer, or a personal digital assistant (PDA). The 
invention may be practiced with other computer system configurations as well, including 

18 
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multiprocessor systems, microprocessor-based or programmable consumer electronics, network 
computers, minicomputers, and mainframe computers. The invention may be practiced in 
distributed computing environments where tasks are performed by remote processing devices 
that are linked through a communications network. 
5 The device 1400 includes one or more of the following components: processor(s) 1402, 

memory 1404, storage 1406, a communications component 1408, input device(s) 1410, a display 
1412, and output device(s) 1414. For a particular instantiation of the device 1400, one or more 
of these components may not be present. For example, a PDA may not have any output 
device(s) 1414. The description of the device 1400 is to be used as an overview of the types of 
10 components that typically reside within such a device, and is not meant as a limiting or 
exhaustive description. 

The processors) 1402 may include a single central-processing unit (CPU), or a plurality 
of processing units, commonly referred to as a parallel processing environment. The memory 
1404 may include read-only memory (ROM) and/or random-access memory (RAM). The 
1 5 storage 1406 may be any type of storage, such as fixed-media storage devices and removable- 
media storage devices. Examples of the former include hard disk drives, and flash or other non- 
volatile memory. Examples of the latter include tape drives, optical drives like CD-ROM drives, 
and floppy disk drives. The storage devices and their associated computer-readable media 
provide non-volatile storage of computer-readable instructions, data structures, program 
20 modules, and other data. Any type of computer-readable media that can store data and that is 
accessible by a computer can be used. 

The device 1400 may operate in a network environment. Examples of networks include 
the Internet, intranets, extranets, local-area networks (LAN's), and wide-area networks 
(WAN's). The device 1400 may include a communications component 1408, which can be 
25 present in or attached to the device 1400. The component 1408 maybe one or more of a 

network card, an Ethernet card, an analog modem, a cable modem, a digital subscriber loop 
(DSL) modem, and an Integrated Services Digital Network (ISDN) adapter. The input device(s) 
1410 are the mechanisms by which a user provides input to the device 1400. Such device(s) 
1410 can include keyboards, pointing devices, microphones, joysticks, game pads, and scanners. 
30 The display 1412 is how the device 1 400 typically shows output to the user. The display 1412 
can include cathode-ray tube (CRT) display devices and flat-panel display (FPD) display 
devices. The device 1400 may provide output to the user via other output device(s) 1414. The 
output device(s) 1414 can include speakers, printers, and other types of devices. 

19 
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The methods that have been described can be computer-implemented on the device 1400. 
A computer-implemented method is desirably realized at least in part as one or more programs 
running on a computer. The programs can be executed from a computer-readable medium such 
as a memory by a processor of a computer. The programs are desirably storable on a machine- 
readable medium, such as a floppy disk or a CD-ROM, for distribution and installation and 
execution on another computer. The program or programs can be a part of a computer system, a 
computer, or a computerized device. 

Conclusion 

It is noted that, although specific embodiments have been illustrated and described 
herein, it will be appreciated by those of ordinary skill in the art that any arrangement that is 
calculated to achieve the same purpose may be substituted for the specific embodiments shown. 
This application is intended to cover any adaptations or variations of the present invention. 
Therefore, it is manifestly intended that this invention be limited only by the claims and 
equivalents thereof. 
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1. An architecture (300) for an automation system, the automation system to control and 
monitor a plurality of devices (3 1 8), the architecture characterized by: 

at least one look-up service (310) to maintain at least one database of the plurality of devices 
5 by a plurality of device attributes including device type and physical location, and of a plurality 
of device objects corresponding to the plurality of devices by mapping a name for each device 
object to at least one address for each device object; 

a soft-state store (316) to manage at least periodic refresh information for the plurality of 
devices and the plurality of device objects, the refresh information managed by the soft-state 
10 store as a plurality of soft-state variables; and, 

a publication/subscription eventing component (312) to enable subscriptions to events 
related to changes in the plurality of soft-state variables managed by the soft-state store. 

2. The architecture of claim 1 , wherein the at least one look-up service is characterized by: 
an attribute-based look-up service (322) to maintain a first database of the plurality of 

1 5 devices by the plurality of device attributes; and, 

a name-based look-up service (320) to maintain a second database of the plurality of device 
objects corresponding to the plurality of devices. 

3. The architecture of claim 2, wherein the name-based look-up service instantiates instances of 
the plurality of device objects. 

20 4. The architecture of claim 2, wherein the second database maintained by the name-based 
look-up service further includes a plurality of computation objects. 

5. The architecture of claim 1 , wherein the at least one address for each device object is 
characterized by a synchronous address for synchronous communication with the device object, 
and an asynchronous address for asynchronous communication with the device object. 

25 6. The architecture of claim 1 , wherein the device and the device object refresh information 
included in the soft-state variables is characterized by periodic heartbeats sent by each entity of 
the plurality of devices and the plurality of device objects. 
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7. The architecture of claim 6, wherein the periodic heartbeats sent by each entity of the 
plurality of devices and the plurality of device objects refresh the entity, such that failure by the 
entity to send the periodic heartbeats as required by a refresh rate for the entity results in 
removal of the entity from the at least one look-up service. 

8. The architecture of claim 6, wherein each entity of the plurality of devices and the plurality 
of device objects has a refresh rate, and the periodic heartbeats sent by the entity are stored by 
the soft-state store in a persistent store where the refresh rate for the entity is lower than a 
predetermined threshold and are stored in a volatile store where the refresh rate is greater than 
the predetermined threshold. 

9. The architecture of claim 1, further characterized by a plurality of system management 
daemons (314) to detect failures in the plurality of devices, and initiate recovery from the 
failures. 

10. The architecture of claim 9, wherein the plurality of system management daemons include a 
power line monitoring daemon (702) to detect problems with the plurality of devices that are 
power line devices. 

1 1. The architecture of claim 10, wherein the power line monitoring daemon uses pattern-based 
detection for detecting unacceptable power line activity. 

12. The architecture of claim 11, wherein the power line monitoring daemon matches power line 
patterns against unacceptable power line patterns stored in a pattern database. 

13. The architecture of claim 10, wherein the power line monitoring daemon uses model-based 
detection for detecting acceptable power line activity. 

14. The architecture of claim 13, wherein the power line monitoring daemon tests power line 
patterns against a pattern model of acceptable power line patterns. 

15. The architecture of claim 9, further characterized by a plurality of instances for each of at 
least one of the plurality of system management daemons, such that the plurality of instances 
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exchange age information, and each instance uses the age information to determine whether it is 
a leader instance. 



16. The architecture of claim 1, wherein the at least one look-up services, the soft-state store, 
and the publication/subscription eventing component reside within a system infrastructure layer 

5 (304) of the architecture. 

17. The architecture of claim 16, further characterized by an application layer (306) in which the 
plurality of device objects reside. 

18. The architecture of claim 17, further characterized by at least one automation application 
(324) and a plurality of device daemons (328) corresponding to the plurality of devices residing 

10 in the application layer. 

19. The architecture of claim 16, further characterized by a user interface layer (308) in which an 
email daemon (336), a voice recognition interface (332), a browser interface (330), and a natural 
language parser interface (334) reside. 

20. The architecture of claim 19, wherein the user interface layer provides for independent 
1 5 verification of a command performed relative to a device within the automation system. 
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